GARP (Generic Attribute Registration Protocol) Virtual Local Area Network (VLAN) Registration Protocol is commonly referred to as GVRP. GVRP is an Open System Interconnection (OSI) Layer 2 network protocol that provides for automatic configuration of Layer 2 devices (referred to herein as bridges) in a VLAN. More specifically, GVRP defines a GARP application that provides for VLAN pruning and dynamic VLAN creation in accordance with IEEE Std. 802.1Q, 2003 Edition, Virtual Bridged Local Area Networks.
A bridge that runs GVRP has the potential for serious problems should a malicious host connected to the bridge produce a high volume of malicious GVRP frames. Each GVRP frame is able to convey advertisements for a large number of VLANs. As a result, the bridge would have to process the registration of thousands of VLANs in a very short timeframe in a repeated manner. This type of malicious activity may cause high CPU load and exhaustion of system resources, which may potentially overwhelm the bridge.
Bridge devices that are 802.1Q-compatible typically support VLAN identifiers in the range from 1 to 4096. This means that in the worst-case scenario, a bridge can create up to 4K VLANs. VLANs can be created manually upon management commands control or dynamically via mechanisms such as GVRP. The processing of GVRP frames (i.e., GVRP Protocol Data Units (PDUs)) involves the mapping of the VLANs advertised on GVRP frames onto the receiving ports, creation of these VLANs on the bridging device and propagation of the GVRP frames within the GIP (GARP Information Propagation) context, which corresponds to the active Spanning Tree topology. Based on the standard definition of the frame format and length as well as the maximum allowed length of Ethernet frames, the maximum number of VLANs that can be advertised on a single Ethernet frame is about 373. This means that in order to advertise VLANs on the range from 1 to 4096, multiple GVRP frames need to be sent in a row to convey this large number of attributes. That said, nothing prevents an attacker from being able to advertise such a number of VLANs.
The processing of GVRP frames may either lead to the creation of VLANs (if the advertised VLANs do not yet exist on the bridge) or simply the mapping of ports to existing VLANs. In either case, the data plane cards where the GVRP frame is received are responsible for performing all sanity and configuration checks. Nevertheless, the data plane cards would need to convey the demand for dynamically creating these VLANs or mapping VLANs onto ports to a central control plane card. That centralized card, in turn, would create or map the requested VLANs and advertise the new status to all interested applications on the bridge. The software operations involved in such creation and/or mapping consume CPU power, inter-process communication infrastructure resources, memory as well as other operating system resources. Accordingly, the processing of many GVRP frames may contribute to a generalized increase in system resources usage. Depending on the implementation, the system in which such VLANS are created may not even have enough CPU capacity or resources to handle this amount of processing in that short time. Furthermore, this may starve some more crucial applications because of an intense GVRP activity.
Most of the relatively low cost Layer 2 devices, especially the ones targeting Enterprise markets, may be brought down due to issues related to high CPU load, high memory consumption and exhaustion of buffers when a large number of dynamic VLAN registrations or de-registrations occur in a bulk. Due to this type of problem, vendors tend to generally caution the user to not create more than a reasonable number of VLANs in the technical literacy provided with bridging equipment. Such issues are likely to happen in specific configurations where GVRP registration is enabled on edge ports (i.e. access ports). Basically, the worse situation would occur if any end-user equipment connected to an edge port would be able to advertise any VLAN across the entire topology. For example, each time the end-user equipment would get switched-on or while running a deliberate malicious script, this equipment would start sending multiple GVRP frames to the first hop bridge that, in turn, may perform standard GVRP processing, thus propagating the multiple GVRP frames.
Although some vendors suggest that a reasonable procedure for precluding such propagation is to disable GVRP on such edge or access ports, the standard foresees the possibility of having GVRP-aware hosts connected to edge ports. Therefore, a desired implementation must be flexible enough to support such kind of configuration. A problem that arises as side effect of this conventional approach for limiting the creation of VLANs at a chassis level of a layer 2 device is that the first data plane card to receive and process GVRP frames may claim all the VLANs defined by a configured system-wide limit.
Therefore, facilitating creation of VLANs using GVRP in a manner that limits the number of VLANs that can be created on a Layer 2 network element and that overcomes drawbacks associated with conventional approaches for creating VLANs using GVRP would be advantageous, desirable and useful.